Back to Contents Previous Next
34. Application memory needs
In order for any Wimp application to run successfully it is essential that it has enough memory space reserved for it.
Using Dr Wimp, there are two critical values that you need to check. They are:
- the ‘
WimpSlot
’
- the size of
wimpmem%
i.e. the second parameter of
FNwimp_initialise
- Section 2.1.
‘WimpSlot’
The WimpSlot is invariably set initially in your application’s !Run file and Dr Wimp follows this standard practice. Have a look in the !Run file of the supplied !MyApp application - or in the application produced by !Fabricate. You will see a line like this:
WimpSlot -min 192k -max 192k
We don’t need to explain this star command in detail - but it worth noting that the spaces in this line and the dashes in front of “min” and “max” are essential. Note also that the same value (here, 192k
- denoting 192 kilobytes) is used in both places. This is another common practice.
In most cases, the WimpSlot is not altered again after its !Run file setting, but DrWimp offers PROCwimp_increaseslot
to allow you to icrease the slot size from within your program if you wish.
The WimpSlot value needs to be sufficient to cope with the total running needs of your application. It needs to cater for at least the following:
!RunImage and DrWimp (and any other) library size
Cumulative size of all window/icon/menu definitions including their indirected data
Variable names and values
Arrays
DIMed memory, but not RMA/Dynamic Areas (DIMmed memory includes any use of the Dr Wimp file-loading wimp-functions for sprite-files/drawfiles etc.)
When you bear in mind that the !MyApp !RunImage and DrWimp library as supplied currently exceed 100kilobytes in size, you will appreciate that a default WimpSlot value of 256 kilobytes gives room for some addition of your code etc.whilst you are working without ‘linking’ or ‘compacting’ - but is by no means generous and might well be exceeded as you develop your application. So you must keep reassessing your WimpSlot needs as the application grows.
A sure sign that the WimpSlot is large enough to load but not large enough to run is the sudden onslaught of (possibly different and apparently unrelated) error messages that you weren’t getting before the last code change. These are signs that the program is overwriting already-created parts of the memory in use. Even the common error “Unknown or missing variable”
can then result - and many others.
If the WimpSlot is too small to allow the application to load then it will probably just ‘hang’ and you will need to resort to <Alt-Break> to clear it.
When you are happy with your application - and/or you have used the post-programming utilities (see Sections 1.7 and 2.35) - you can take steps to reduce the WimpSlot size. A good idea for this purpose is temporarily to add the line:
VDU4 : PRINT (END-PAGE) : VDU5
just before the natural end of your program i.e. just before Line 100 of the !RunImage in the supplied !MyApp.
Then, when you Quit the application, you will get a value shown (in bytes) - normally in a small Task Window. This will be approximately the minimum size of the WimpSlot needed. So add a small amount to it and divide it by 1000 to get a rough number of kilobytes needed. Then change both the values in the !Run file line accordingly.
But remember exercise your program before taking the above Quit action - otherwise the reported value is likely to be too low for safety. (Indeed, it is interesting to compare the values from quitting immediately after loading and then after loading and exercising it.)
Also, try to remember that if/when you revisit the application to upgrade it, you are sure to want to use the unlinked and uncompacted source version - and these are unlikely to work with a WimpSlot size reduced for a ‘released’ version .........
‘wimpmem%’
This variable appears solely in the second parameter of:
FNwimp_initialise(name$,wimpmem%,ver%,desktopsave%)
which is called just once (see Line 80 of !RunImage of supplied !MyApp). Its default setting is 7000 (bytes) in the supplied !MyApp or via !Fabricate.
The value you enter here needs to be large enough to hold the largest single window definition to be used in the application. Each window needs 88 bytes plus 32 bytes for each icon within it (plus any indirected data) - including any icons that might be added to a window by creation within the program. Thus, the default of 7000 will cope with around 215 icons in a window (without indirected data). This should be adequate for many applications.
If you are using the supplied !WinEd window template editor, the ‘‘Statistics’ option from its main menu will supply the necessary value for you - but remember to add more for any icon creation within the program. (Note also that you need to ensure that there is sufficient space for the maximum indirected text lengths that you have specified in the window/icon/menu definitions - and not just the sizes that you might use initially. !WinEd’s ‘Statistics’ window takes this into account.)
Top of page Back to Contents Previous Next